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ATLAS: A Unit-Under-Test Oriented 
Language for Automatic Test Systems 

An engineer can write test procedures in ATLAS without 
detailed knowledge of the system that will do the testing. 
HP's new ATLAS compiler is the first comprehensive 
implementation of what is fast becoming a world-wide 
standard test language. 

by William R. Finch and Robert B. Grady 



ATLAS is an English-like language for writing test 
procedures for electronic equipment. It is de- 
signed to be easily understood by programmers, en- 
gineers, and technicians, and its syntax (grammar) 
is well structured to guarantee an unambiguous 
description of the test procedure, one that can be 
translated by a computer into instructions that con- 
trol automatic test equipment. 

ATLAS is an acronym for Abbreviated Test Lan- 
guage for Avionics Systems. Originally designed, as 
its name implies, for testing avionics equipment, it is 
fast becoming a world-wide standard language for 
general-purpose automatic testing. The official stan- 
dard for the language is maintained by Aeronautical 
Radio Incorporated (ARINC). Hewlett-Packard has 
participated in the standardization effort since 1970. 

HP ATLAS 

HP ATLAS is a new compiling system designed 
to run on HP 9500 Series Automatic Test Systems. 
The principal programming language for these 
systems has always been a form of interactive BASIC, 
now evolved to a high level of specialization for con- 
trol of automatic test systems and called ATS BASIC. 
HP ATLAS is a higher-level language than ATS BASIC 
in much the same way that FORTRAN and COBOL 
are higher-level languages than assembly language. 
Where the ATS BASIC programmer must specify in 
detail how to set up individual test instruments and 
route signals, the ATLAS programmer need only be 
concerned with the requirements of the unit under 
test (UUT). ATLAS test procedures are independent 
of the specific automatic test system that will perform 
the tests. An ATLAS test procedure for a particular 
UUT can be employed by many users who may have 
different system configurations. Clearly this makes it 
much easier to solve applications software problems 
that are common to several users , and this is one of the 



principal reasons for implementing ATLAS on 9500 
Series Systems. 

The HP ATLAS Compiler analyzes test procedures 
written in ATLAS and generates segmented test 
programs in ATS BASIC. It can produce ATLAS 
listings or mixed listings with ATLAS and ATS 
BASIC statements properly interleaved to aid in pro- 
gram debugging. Subroutines written in ATS BASIC, 
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FORTRAN, or assembly language may be called from 
HP ATLAS. 

HP ATLAS is compatible with and meets the stan- 
dards of ARINC ATLAS 416-10. It is the first imple- 
mentation of a comprehensive subset of this official 
standard and is not just a highly adapted pseudo- 
ATLAS. Because it is unit-under-test-oriented, elec- 
tronics and avionics suppliers can use ARINC- 
ATLAS-compliant procedures on HP 9500 Series 
Systems with a minimum of program rewriting and 
personnel retraining. 

Introduction to ATLAS 

An example of an ATLAS statement is: 



preceding each statement. The statement can con- 
tinue on separate lines at any point except where end- 
ing the line would split a word. The symbol $ is the 
statement terminator. The HP ATLAS implementa- 
tion does not require commas as separators, although 
at least one space between words is required where 
the ARINC specification requires a space or comma. 
Other ATLAS statements, called procedure-ori- 
ented statements, are used to analyze and output test 
results and control the execution sequence of a test 
procedure. These include facilities for variable assign- 
ments, mathematical calculations, branching, loop- 
ing, block structure, test operator interaction, and 
other program control functions similar to other high- 



APPLY, DC SIGNAL, 

VOLTAGE 10 V ERRLMT +-0.1 V, 
CNX HI J4-1 LO J3 $ 

The English equivalent of this statement is: apply 
10 ± 0.1 Vdc between UUT pins J4-1 and J3. In this ex- 
ample, APPLY defines what to do with the signal, the 
phrase DC SIGNAL, VOLTAGE 10 V ERRLMT +-0.1 V des- 
scribes the type and characteristics of the applied 
signal, and CNX HI J4-1 LO J3 names the UUT input con- 
nections. 

Another example of an ATLAS statement is: 

MEASURE, (FREQ ERRLMT + -0.002 MHZ), AC SIGNAL, 
FREQ RANGE 4 MHZ TO 6 MHZ, 
VOLTAGE RANGE 1 V TO 1.5 V, 
CNX HI Jl-1 LO Jl-2 $ 

The words MEASURE (FREQ) describe the required 
action, AC SIGNAL specifies the type of signal, the 
characteristics for frequency and voltage provide 
the signal description, and the CNX field specifies 
the UUT output pins. This statement defines the test 
function as: measure the frequency, with required mea- 
surement accuracy of ±0.002 MHz, of an ac sig- 
nal having expected amplitude and frequency char- 
acteristics of 1 to 1.5 Vac at 4 to 6 MHz present at 
UUT output connector pins Jl-1 and Jl-2. 

The first example above is classified as a source- 
type ATLAS signal-oriented statement. The state- 
ments in this class provide the stimulus function. 
The second example is a sensor-type ATLAS signal- 
oriented statement. These provide the response mea- 
surement function. A sequence of ATLAS statements 
must describe the test procedure in sufficient detail 
to allow the HP ATLAS Compiler to generate an exe- 
cutable program for an automatic test system. The 
readability of ATLAS statements makes it possible for 
the same test procedure to be performed manually 
using bench instruments. 

ATLAS uses commas to separate fields within a 
statement. There will usually be statement numbers 




fstatno CALCULATE 



$ 



fstatno represents the flag and statement number fields, which are 
always optional in HP ATLAS. 



represents a subdiagram. Any of the legal combinations 



shown in a subdiagram are legal in the context where the 
dashed box is used. 



ri 



represents a branch. Any one of the paths can be used to 
form a legal statement. 



represents a loop, and the part of the graph shown within its 
bounds can be repeated as many times as necessary. 



indicates that a branch can be taken which omits a keyword, 
and the keyword will be reconstructed on the HP Preferred 
Listing. 
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E003010 CALCULATE, A' = 3, 'B' 
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Illustrates Looping and Branching 

OUTPUT7.707$ 



Illustrates Optional fstatno 
and CALCULATE 



Fig. 1. A syntax diagram for a calculate statement, a typical 
ATLAS procedure oriented statement. Syntax diagrams spec- 
ify the rules for constructing all the legal forms of ATLAS 
statements. 



level computer languages. The complete list of HP 
ATLAS verbs, nouns, and modifiers is given in the 
table on page 12. 

ATLAS statements have many optional forms. The 
rules for constructing them are specified by syntax 
diagrams, such as that shown in Fig. 1 for the verb 
CALCULATE. 

Automatic Resource Allocation 

Now let's examine a typical ATLAS statement to 
understand what the ATLAS compiler is required to 
do. 



adapter/interface, and the ability to select signal paths 
from the connections Jl-15 and Jl-10 on the UUT 
to pins HI and LO on the measurement instrument. 
Combining all of these concepts together into a sin- 
gle high-level language statement and taking into 
account parallel signal activity demands consider- 
able intelligence for a compiler, and the processes it 
must perform are called automatic resource alloca- 
tion. It is this capability of the HP ATLAS Compiler 
that makes it possible to program a test without speci- 
fic reference to the system instrumentation and 
switching hardware. 



MEASURE (VOLTAGE), DC SIGNAL, 
VOLTAGE MAX 10V, 

CNX HI Jl-15 LO Jl-10 $ 

First of all, MEASURE implies that one or more in- 
struments must measure some electronic or non- 
electronic signal characteristic or event. Compare 
such a verb with the FORTRAN verb READ, and you 
can see that both expect a result from a device exter- 
nal to the computer. But where a FORTRAN READ 
represents simply a data transfer, MEASURE implies 
additional setups and adjustments to potentially 
complex instrumentation. 

DC SIGNAL and VOLTAGE max io v provide enough 
information to determine what instruments in a sys- 
tem can perform the measurement. This implies a 
choice among a variety of instruments, especially in 
the simple case in our example of a low-level dc sig- 
nal. The CNX field implies knowledge of all switch- 
ing and wiring in the complete test system and 



Two Processors Aid Compiler 

To translate the signal-oriented statements of an 
ATLAS test procedure into an ATS BASIC program, 
the compiler requires two kinds of information in ad- 
dition to the test procedure (see Fig. 2). First, the ca- 
pabilities and method of programming the instru- 
mentation and switching hardware of the target auto- 
matic test system must be known. Second, the charac- 
teristics of the interface between the target system 
and the specific unit under test must be known. HP 
ATLAS provides two processors that accept this in- 
formation in high-level languages and automatically 
translate it into a form that can be used by the HP 
ATLAS Compiler. Fig. 3 shows the processor/com- 
piler relationship. 

The ATE Processor accepts descriptions of instru- 
ments, relays, interface panels, internal wiring, and 
methods of programming, all in a language very simi- 
lar to ATLAS (see Fig. 4). Its output consists of data 
files that model the system's interface, switching, 
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MEASURE, (VOLTAGE), DC SIGNAL, 
VOLTAGE MAX 1000 MV 




Adapter/ 

Interface 

Information 



CNXHIJ1-15LOJ1-10 



Fig. 2. A typical automatic test 
system configuration showing the 
relationship between parts of an 
ATLAS statement and parts of the 
system. The compiler must be giv- 
en information about the system 
so it can automatically allocate 
system resources to execute the 
ATLAS program. 



Automatic Test Equipment (ATE) 

Adapter/Interface (A/1) 

Unit Under Test (UUT) 




^> 



ATE Phase I 
i Command Processing 
» Source Listing 
* Syntax Analysis 
» Formatted Listing 



ATE Phase II 
» Build Device Models with 

Macro Requirements Data 
» Build ATE Switching and 

Wiring Model 
• Generate Output Files 
i Diagnostic Summary Listing 



ATE Identification 
ATE Panel Pin Formulas 



A/I Phase I 
» Command Processing 
» Source Listing 
» Syntax Analysis 
» Formatted Listing 




ATE Configuration Files 



ATE Switching and 
Wiring Model 



•<S 



• Integrate ATE Switching/ 

Wiring Model and Adapter/ 
UUT Interconnection Data 

• Generate Output Files 

• Diagnostic Summary Listing 




Adapter Interface Files 



ATLAS Phase I 

* Command Processing 

* Source Listing 

» Syntax Analysis 
> Formatted ARINC 
ATLAS Listing 
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ATLAS Phase II 
» Translate Procedural ATLAS 

Statements to Primitive Form 
> Symbol Table Cross 

Reference Listing 
» UUT Pin Cross 

Reference Listing 



ATLAS Phase III 
» Signal Identification 
» Signal Requirements 

Analysis 
* Signal Scope Analysis 
» Signal Requirements 

Cross Reference Listing 



Device Models and Macro 

Parameter Requirements 



ATE/UUT Wiring 
and Switching Model 



ATE Macros 
ATE Memory Sia 



ATLAS Phase IV 

► Device Qualification 

for Each Signal 
» Switch Selection for Each 

Qualified Device to 

UUT Pins 
» Resolution of Resource 

Conflicts and Selection 

of Resource Se 
* Translate Signal ' 

Statements to Primitive Form 

► Signal/Device Cross 

Reference Listing 



ATLAS Phase V 
■ Translate Procedural and 
Macro Primitives to 
ATS-BASIC 

• Segment ATS-BASIC to Fit 

Target ATE Memory Area 

• Interleaved ATLAS/ 

BASIC Listing 
» Diagnostic Summary Listing 

• Translate ATS-BASIC 

to Executable Form 



Executable ATE Oriented 
Test Program -* 



c 
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Fig. 3. The HP A TLAS Compiler has five phases and makes use of information from two auxiliary 
processors. The ATE Processor accepts a description of system capabilities (supplied with 
each HP 9500 Series System) and generates disc files for the All Processor and the HP ATLAS 
Compiler. The All Processor accepts a user-written description of the adapter /interface between 
the system and the unit under test (UUT), integrates the description with the system switching 
and wiring model supplied by the ATE Processor, and generates disc files for the HP ATLAS 
Compiler. The compiler uses the appropriate ATE and All files to translate UUT-oriented ATLAS 
test procedures to system-oriented ATS BASIC test programs. 



and instrument capabilities and the method of pro- 
gramming the system. The information required by 
the ATE Processor is supplied with HP 9500 Systems. 
The Adapter/Interface (A/I) Processor accepts a de- 
scription of the connections between the test system 



and the UUT (see Fig. 4). Its output consists of data 
files that are a composite model of the system switch- 
ing capabilities and all the interconnections within 
the system and between the system interface and the 
UUT interface. 



ATLAS Source 



APPLY, AC SIGNAL* FREb 10 KHZ, VOLTAGE . 5V* CNA hi J4-] LO J35 



ATE Source 



DEFINE, ■HP3320P' 

c s 

SPEC1FY*C0NTACTS* 

SPECIFY* SOURCE* 

fc ^ SIGNAL* 
FRES RANGE 



VOLTAGE RANGE 



OUTPUT-HI 
OUTPUT-LO « 



1.3MHZ TO 1 3MMZ FY 1KHZ 

ERRLMT + - 1 . 3KHZ 

130KHZ TO 1299. 9KHZ BY 0.1KHZ 

ERRLKT +-130hZ 

I3KHZ TO 129.99KHZ BY 0.0IKHZ 

FRRLMT *-13HZ 

I.3KHZ TO 12.999KHZ BY 0.001KH 

ERRLMT + -I .3HZ 

130HZ TO 1299. 9HZ BY 0.1HZ 

ERRLMT *-0. 13HZ 

13HZ TO 129.99MZ BY W.01HZ 

ERRLMT +-0.013HZ 

0.001HZ TO 12.999MZ BY 0.001MZ 

ERRLMT +-0.0013HZ 

100MV TO 5000MV BY 10MV 

ERRLMT +-260MV 

0.05MV TO 100MV BY 10MV 

ERRLMT + - 100X 

V TO 0.0 5MV/ BY 10MV 

ERRLMT +-100X 



IMP 50 OHM 

CNX HI OUTPUT-HI ■ 

LO OUTPUT-LO S 

DEFINE*SETUP*OPEN*MACRO S 

* ACVSV < *P1 '* 10*0. 1 )FAIL: INVOKEC 64) 

END* SETUP*OPEN*MACRO S 



DEFINE* CLOSE* MACRO S 

♦ACVSV < 'PI '* '♦FREQ'* ' + VOLTA • >FAI L : INVOKE< 64) 

*WAIT( 100) % 

END*CLOSE*MACRO $ 



DEFINE/ 


'HP25000H 1 , SWITCH 


« 


SPECIFY/ 


RELAYS 
POLES 


K<1.32> . 
1 . 






ARM 


IN . 






THROk 


OUT 


5 



DEFINE. CONNECT. MACRO S 

•SSkSR I I. "PI '>FA1L!INV0KEC64> 
END. CONNECT. MACRO t 

5 
DEFINE. DISCONNECT, MACRO S 
•SSWSR (0* 'PI ')FAILI 1NV0KEC64) 
END. DISCONNECT. MACRO $ 



c 



« 



DECLARE 'SICGEN 1 DEVICE 

TYPE 'HP3320B' 'PI' 
CONTACTS 3320-HI 

3320-LO § 

DECLARE SUTCH, TYPE 'HP25000H'. START 577 S 



C 



5 



CNX 
CNA 
CNX 



CNX 
CNX 



3320-HI 
3320-LO 
PNLA-3320-HI- 



PNLA-3320-HI-A 

PNLA-3320-LO-A S 
PNLI-26-A 



PNLA-3320-LO-C PNLI-27-X 

PNLI-3-0L 

PNLI-4-0L 



K577-I-1N ■" 
KS77-1-0UT 



A/I Source 



PNL1-26-X 
PNLI-4-0L 
J3 GROUND S 



PNL1-3-0L 
J4-I $ 



Device Template: For a single function of a device, 
describes performance criteria, connection points, 
and translation information. Information in a 
template is independent of system configuration, 
and is tied into a specific system by a declaration. 



Switch Template: Specifies relay type, how many 
► relays per template, names of all associated pins 
(offset from address 0), and translation information. 



Declarations: Declares unit number (or relay num- 
bers) and system unique names for each instance of 
a oevice or switch in a system. 



Wire List: From/to wire list of complete system. 



A/I Wire List: From/to wire list of UUT to interface 
panel. 



ATLAS Source with BASIC Output 



c $ 

100000 APPLr, AC SIGNAL, FREU 10 KHZ, VOLTAGE .5V, CNX HI J4-1 LO J35 

210 ACVSV < I* 10. 0.1 >FAIL: INV0KE<64>^ 

215 SSkSR < l,577)FAIL:INVOKE<64>- 



220 ACVSV ( 1 . 1000*( 10). .5>FAIL: INV0KE(64)1 
225 UAIT<100> 



Setup Macro 
Connect Macro 
Close Macro 



Fig. 4. Samples of input code for the ATE and All Processors showing relationships with ATLAS 
source code and the equivalent ATS BASIC output. Arrows at the left show how the ATLAS Com- 
piler compares signal characteristics with device capabilities. Arrows at the right show how the 
compiler traces signal paths between a device and the unit under test. 



Three Compiler Modes 

The HP ATLAS Compiler uses the data produced 
by the ATE and A/I Processors to select instruments 
and switching hardware and to generate signal- 
oriented object code. The compiler can be operated 
in any of three primary modes. 

For an initial check of an ATLAS test procedure, 
the compiler can be operated with neither the target 
system nor the adapter/interface defined. The com- 
piler performs a considerable amount of analysis on 
the procedure's syntactic correctness and signal re- 
quirements. Operating in this mode, the compiler is 
really a test procedure analyzer, since it generates no 
object code. The signal requirements cross reference 
and diagnostic information that are produced are, 
however, of considerable value during test procedure 
development. 

If an ATLAS test procedure is compiled for a speci- 
fic target system, but the adapter/interface is not de- 
fined, additional analysis is performed to determine the 
degree of compatibility between the signal require- 
ments in the test procedure and the available instru- 
mentation in the system description. The output, a 
signal requirements/device cross reference and diag- 
nostic summary, reflects this compatibility. Operat- 
ing the compiler in this mode, the user can determine 
whether or not the target system can perform the test 
procedure as written, and can determine the system- 
to-UUT interconnections that are required. 

If an ATLAS test procedure is compiled with a de- 
fined system and adapter/interface, the compiler will 
generate the appropriate ATS BASIC program for per- 
forming the test procedure. 

Compiler Functional Description 

The HP ATLAS Compiler is organized into five 
phases, each of which performs a group of related 
operations that contribute to the overall translation 
process (Fig. 3). In general, these subprocesses oper- 
ate on the internal representation of the ATLAS test 
procedure, often in conjunction with data from the 
A/I Processor, the ATE Processor, and the earlier com- 
piler phases. Each subprocess either modifies the in- 
ternal representation of the test procedure, thus con- 
tributing directly to the translation process, extracts 
and processes related information from the test proce- 
dure, thus contributing indirectly to the translation 
process, or formats information for the purpose of 
generating printed listings. 

Phase I 

The primary purpose of the first phase is to process 
compiler commands and to detect and identify test 
procedure errors in word construction, required 
punctuation, statement composition, or statement 
grouping. Some compiler commands have an imme- 



diate effect, directing phase I to obtain source code 
from particular input devices or disc files, or causing 
source listings or files to be generated. Other com- 
mands that affect later processes are noted for future 
reference. 

The test procedure is input in the form of an ASCII 
(American Standard Code for Information Inter- 
change) character stream from disc files, input de- 
vices, or the operator's console keyboard. Input char- 
acters are grouped together to form syntactic units. 
The compiler replaces each unique syntactic unit by 
a unique number, called a token, to facilitate efficient 
processing. The various syntactic units, such as AT- 
LAS keywords (or abbreviations: the compiler re- 
quires only three or more leading characters of a key- 
word that uniquely identify it), punctuation, numeric 
constants, variable names, UUT pin names, and so 
on, are assigned token values in numeric groupings 
or ranges so the type of syntactic unit can be easily 
identified by the range of the token value. For ex- 
ample, verbs are assigned token values between 
100 and 165. 

The resulting token stream is then compared with 
acceptable ATLAS syntactic forms. During this pro- 
cess, omissions of certain parts of strict ARINC AT- 
LAS syntax, considered optional in HP ATLAS, are 
detected and the missing tokens are inserted into the 
token stream for conformity to ARINC ATLAS. State- 
ment numbers, commas, and some keywords fall into 
this category. If required, the statements are renum- 
bered to comply with the ARINC requirement for in- 
creasing statement numbers. In addition to state- 
ment syntax checking, syntactic requirements that 
apply to the relationships between two or more state- 
ments, or to the test procedure in general, are veri- 
fied. A listing of the test procedure in preferred 
ARINC ATLAS format is then generated (see Fig. 5). 
This listing includes full spellings, punctuation, and 
block indentations. 

Phase II 

The second compiler phase translates all procedur- 
al statements (non-signal-oriented statements) into 
an intermediate form called primitive code. This pri- 
mitive code is independent of any particular ob- 
ject code, but is easily translated into any lower- 
level language. The translation of procedural state- 
ments is quite conventional in many respects, and a 
detailed discussion will not be given. One unusual 
aspect of the translation, however, is that ATLAS 
PROCEDURES are expanded "in-line" each time they 
are called by a PERFORM statement, instead of being 
expanded once and thereafter treated as subroutines 
to be invoked by PERFORM statements. This is neces- 
sary for two reasons. One is that UUT pins may be 
used as procedure parameters. If the procedures were 



SLIST BASIC 


000000 


BEGIN* ATLAS PROGRAM '09540-900 1 7 '5 


01 


DEFINE. 'INPUT'. SOURCE S 


02 


DECLARE, DECIMAL. LIST, 'V0UT'<5>, 'FREO'(5)S 


03 


DECLARE, DECIMAL, LIST, 'ULIM ■< 5>. 'LLIM '( 5)5 


C S 




04 


FILL, 'VOUT', 'ULIM', 'LLIM '. 




( l>. 10, ■ 105, .095, 




(2> .05, .055, .045. 




( li .0 1 , .0)3, .007, 




( 4) .005, .007, .003, 




C 5> .001, .003, .00$ 


C 5 








C 5 




05 


FOR "INDEX'=1 THRU 5, THEN S 


06 


ADJUST, AC SIGNAL, 




•INPUT', 




VOLTAGE -10 V, 




FREQ RANGE 50 KHZ TO 200 KHZ BY 1 KHZ RATE 10 KHZ 




/ SEC, 




CNX HI J4-1 LO J3S 


07 


TO REACH, (VOLTAGE), AC SIGNAL, 




NOM 'VOUT'C 'INDEX ') V UL ' ULIM ' C 'INDEX ' ) V LL 




•LLIM '( 'INDEX ') V, 




VOLTAGE RANGE V TO .IS V, 




CNX HI J4-8 LO J3S 


08 


MEASURE. (FREQ INTO ' FREQ '( "INDEX •>) , AC SIGNAL, 




VOLTAGE .10 V, 




FREQ RANGE 50 KHZ TO 200 KHZ, 




CNX HI J4-1 LO J3£ 


09 


END, FOR 5 


C 5 




10 


RECORD, 'FREQ'. (1 THRU 5) TO EXTERNAL 'D1000'S EX 


1 1 


FINISH ? 


12 


TERMINATE. ATLAS PROGRAM 5 



Fig. 5. Typical ATLAS program listing in preferred ARINC for- 
mat, produced by compiler phase I. Extensions to ARINC 
ATLAS are flagged by an EX in the righthand column. 



treated as subroutines, the UUT pin parameters 
would have to be treated as variables within the pro- 
cedures. Because signal switching is decided at com- 
pile time, implementation of UUT pin variables is 
not possible. Second, signal-oriented statements 
must be considered with respect to all other signals 
that are active concurrently when allocation of sys- 
tem resources is done automatically. Because the sig- 
nal activity context may differ between one PERFOR- 
MANCE of a PROCEDURE and another, the same signal- 
oriented statement may translate differently in dif- 
ferent instances. 

At the conclusion of phase II, alphabetized cross 
reference listings of user-defined symbolic labels 
and UUT pin names are generated if activated by the 
$xref LBL command. 

Phase III 

The third compiler phase does a detailed analysis 
of the signal activity that will be present at the UUT/ 
system interface throughout the performance of the 
test procedure. This analysis results in a highly struc- 



Minimizing Test Program 
Expenses 



The benefits of automatic test equipment are well known, the 
principal ones being faster, more repeatable testing even with 
relatively unskilled operators. 

However, test program preparation can be expensive. There 
are many hidden costs. Early in the design phase of HP ATLAS 
every aspect of that expense was examined not only to maximize 
the value of the final product, but also to minimize the de- 
velopment cost. 

The most visible element of a system expenditure is the hard- 
ware environment in which the compiler and output programs 
operate. HP ATLAS operates on HP 9500 Series Automatic 
Test Systems. Thus computer and peripheral expenses are 
held to minicomputer levels while additional processing power 
is provided by using a disc operating system for compilations. 
The compiler is flexible enough to operate within different con- 
figurations and to compile programs for execution on various 
test station configurations. 

A second test preparation expenditure is UUT/system 
adapter costs and the associated costs of integrating special 
hardware and switching into the system for special UUT needs. 
The ability to describe the system configuration and the 
adapter/interface configuration in high-level language terms 
helps to minimize the integration costs. Also, one phase of the 
compiler is dedicated to signal requirements analysis and pro- 
duces listings that can be used to aid in adapter design, or 
even in selecting the most appropriate system for testing a 
UUT. 

The third expenditure and potentially the largest is direct pro- 
gramming expenses. This expense is addressed by the ATLAS 
language, which is English-like, uses engineering terms, and 
can be used without detailed knowledge of the system hard- 
ware, thereby simplifying the writing of test programs. But this 
alone is not necessarily enough, because high-level languages 



require more computer processing time than lower-level lan- 
guages. To minimize this effect, the HP ATLAS Compiler 
helps reduce the length of compiles by providing partial- 
compilation capability and several levels of well-designed 
error diagnostics. 

Potentially the greatest source of savings in an ATLAS sys- 
tem is that many common system-dependent errors are mini- 
mized by providing common instrumentation and switching rou- 
tines in preprocessed data files. These errors include 

■ wrong switching 

i incorrect settling delays 

• wrong device setups or ranges 

■ wrong tolerances because of dimensional changes 

• device interactions. 

The reduction of this broad class of problems reduces costs 
by shortening the time needed for program verification. Once a 
program compiles successfully, the probability of execution is 
good. 

Many users of automatic test equipment encounter a fourth 
cost because they have many different systems that must per- 
form the same tests. Using test-system-dependent languages, 
a separate program would be required for each type of system. 
If a system-independent language like ATLAS is used, a pro- 
gram written for one system is transportable to another with 
only minor modifications, if any. 

The last major area of system cost is support. High-level lan- 
guages generally minimize this cost, because they inherently 
contain more support documentation value than lower level lan- 
guages. HP ATLAS further aids this task by outputting a pre- 
ferred listing using standard ARINC ATLAS spellings, punctua- 
tion, and formatting. System-independent ATLAS also reduces 
support costs by reducing the number of different programs 
required when different systems perform the same tests. 



tured data file which represents the stimulus signals 
required by the UUT, the UUT signals that are to be 
measured, and the loads that are to be applied to the 
UUT. This analysis of UUT signal requirements is 
done independently from any system configuration 
information, but results in a precise specification of 
the system capabilities required to perform a given 
test procedure. 

To determine the UUT signal requirements, all sig- 
nal-oriented statements are processed to determine 
how many signals exist and which statements refer 
to each signal, whether each signal is a SOURCE, SEN- 
SOR, or LOAD, the signal type or noun, the signal char- 
acteristics, normalized characteristic dimensions or 
units, range of values, accuracy requirements, and the 
UUT pins associated with the signal. 

In addition, all statements that affect the execution 
sequence of a test procedure (IF, FOR, WHILE, REPEAT, 
and GO TO statements) are examined and the range of 
statements over which each signal is active is deter- 
mined. This information, called signal scope, is then 
used to identify signal concurrency, that is, signals 
that have overlapping periods of activity when the 
test procedure is executed. 

An optional listing, activated by the $XREF SIG com- 
mand, provides a formatted representation of the sig- 
nal requirements analysis, which is highly useful for 
evaluating the signal activity in an ATLAS test 
procedure. 

Phase IV 

The primary purpose of the fourth compiler phase 
is to determine the system resources that are to be 
used for each signal identified and specified by 
phase III, and to then translate the signal-oriented 
statements into primitive code form. 

First, for each signal requirement, each system de- 
vice model that compares favorably with the signal 
requirement is noted along with device parameter in- 
formation. This results in a device candidate list for 
each signal requirement. Second, the system/UUT 
switching and wiring model is used to determine 
whether or not the terminals on the device candi- 
dates can be connected to the required UUT terminals. 
If they can, the required switching and signal path 
resources are recorded, along with the device, as the 
set of required resources for the candidate. If signal 
paths from candidate device terminals to UUT ter- 
minals cannot be established, the candidate is dis- 
qualified from further consideration. 

For each signal requirement having one or more 
qualified candidates (sets of resources that satisfy the 
signal requirements), a tentative candidate assign- 
ment is made. The specific resources associated with 
the tentative candidates for concurrent signals are 
cross-checked to detect allocation conflicts. If alloca- 



tion conflicts occur and either of the concurrent sig- 
nals has candidate alternatives, the tentative candi- 
date assignment is changed in an attempt to resolve 
the resource conflict. If a combination of candidates 
cannot be found which resolves a resource conflict 
between concurrent signals, one of the signal require- 
ments is identified as being unallocatable. Conflict 
detection and resolution continues until allocation 
is completed. All surviving tentative allocations 
then become actual allocations. 

Once resource sets are allocated for all signal re- 
quirements, primitive code is generated for each sig- 
nal-oriented statement, based on the resource set as- 
sociated with the signal requirement of which the sig- 
nal-oriented statement is a part. Following the gener- 
ation of primitive code, an optional signal/device 
cross reference listing may be generated (Fig. 6). This 
is similar to the signal cross reference listing of Phase 
III, but contains additional information about device 
qualification and disqualification and allocations 
for each signal requirement. 



SIGNAL REQUIREMENTS CROSS REFERENCE 



SENSOR CROSS REFERENCE 



AC SIGNAL (VOLTAGE)* 
CHARACTERISTICS: 

VOLTAGE MIN V; MAX .12 V) 
REFERENCES: 

TO AT 0000071 CNX HI J4-8 LO J3 
SCOPE OF ACTIVITY: 



SELECTED 
DISQUALIFIED 



DEVICE CANDIDATES: 
* 'DVM* FUNCTION 2A 
"DVM * FUNCTION 2C 



NO SIGNAL PATH FOR CNX HI J4-8 

3: AC SIGNAL CFREQ), 
CHARACTERI STICS: 
VOLTAGE . 1 V) 

FREQ MIN 50E3 HZ) MAX 200E3 HZ) 
REFERENCES: 

MEASURE AT 000008) CNX HI J4-1 LO J3 ) 
SCOPE OF ACTIVITY: 

000008 
DEVICE CANDIDATES: 

♦'COUNTER' FUNCTION 1 SELECTED 
'COUNTER' FUNCTION 2A QUALIFIED 
•COUNTER' FUNCTION 28 DISQUALIFIED 

VOLTAGE NOT SPECIFIED FOR CANDIDATE 



SOURCE CROSS REFERENCE 

1 : AC SI GNAL 'INPUT'* 
CHARACTERISTICS: 
VOLTAGE .1 V) 
FREQ MIN 50F3 HZ) 
10000 HZ 
REFERENCES: 

DEFINE AT 000001 ) 
ADJUST AT 000006) C 
FINISH AT 0000 1 1 ) 
SCOPE OF ACTI VI TY : 

FROM 000005 TO 000011 
DEVICE CANDIDATES: 

'SIG. GEN' FUNCTION 1 DISQUALIFIED 

VOLTAGE NOT SPECIFIED FOR CANDIDATE 
* 'SIG. GEN' FUNCTION 2 SELECTED 
'HFSIC.GEN1' FUNCTION 1 DISQUALIFIED 
VOLTAGE NOT SPECIFIED FOR CANDIDATE 
FREQ MAX OUT OF CANDIDATE RANGE 
FREQ MIN OUT OF CANDIDATE RANGE 
'W0RD.GEN1' FUNCTION 1 DISQUALIFIED 

VOLTAGE NOT SPECIFIED FOR CANDIDATE 
FREQ MAX OUT OF CANDIDATE RANGE 
'W0RD.GEN2' FUNCTION 1 DISQUALIFIED 

VOLTAGE NOT SPECIFIED FOR CANDIDATE 
FREQ MAX OUT OF CANDIDATE RANGE 



00F3 



RESOLUTION 1000 ^li RATE 



J 4-1 LO J 3 



Fig. 6. Signal/device cross reference is produced by 

compiler phase IV. 



Phase V 

The fifth and final phase of the compiler translates 
the primitive code stream into executable object 
code; specifically ATS BASIC and/or ATS BASIC in- 
termediate code. This process consists of a number of 
interrelated operations, including expansion of de- 
vice programming procedures as specified by the 
primitive code, translation of procedural primitives, 
mapping ATLAS variables and compiler generated 
variables into BASIC variables, and segmenting ob- 
ject code to fit the target system core environment. 
Also generated are an initialization code sequence for 
initializing variables and opening any required disc 
files, and an operator interaction sequence for selec- 
tion of optional starting points in the test procedure. 

If activated by a $LIST BASIC command, phase V 
generates an interleaved listing of ATLAS and ATS 
BASIC (Fig. 7). Then a summary of any errors or warn- 
ings detected during the compilation is produced. If 
either a $OBjECT <file-name> or $BASIC <file-name> 
command has been given, a file of commands for the 
ATS BASIC interpreter is generated for directing the 
further processing of the segmented test program. 
Then the input phase of the ATS BASIC interpreter 
completes the translation process. 

Designed for Efficient Use 

The HP ATLAS Compiler was designed assuming 
two types of users: one or more ATLAS test procedure 
writers who are technicians or engineers and are ex- 
perts in understanding UUTs, and an ATE and A/I 
specialist who is familiar with the system and its in- 
terfaces and who is responsible for system upgrades, 
methods of use, and adapter design. These two users 
can be the same individual, but on a complex system 
with multiple users it probably makes sense to assign 
one ATE and A/I specialist. 

The compiler offers the user a number of options 
that facilitate its efficient use. For example, assume 
the user has prepared a test procedure using abbre- 
viated ATLAS and has punched it on paper tape or 
cards. To this source program the user can add com- 
piler command statements that control the options 
available (see table, page 12). This can be done either 
by typing the commands at the operator's keyboard or 
by editing the source program. For the initial run 
the user would probably add the following options 
(compiler commands begin with the $ symbol): 

$SAVE ATLAS S20000 
$THRU MAX - 1 
C PROGRAM BEGINS HERE $ 
BEGIN $ 



1 10 OPENC 7, 1000, GC6) ) 

115 IF GC6)>0 INV0KEC64) 

120 RESETC7.0) 
ASIC 
BEGIN, ATLAS PROGRAM ■09540-90017*5 
DEFINE. 'INPUT', SOURCE S 

DECLARE, DECIMAL- LI ST, 'VOUT 'C 5), 'FREG'C 5)S 
DECLARE, DECIMAL, L15T, 'ULIM'CS). 'LLlM'tSIS 



ILL- 'VOUT ", 'ULIM ', 
345, C3> .01 . .013, .0' 
30 S 
125 LET BC 1 ) = . 1 
130 LET DC 1 )= . 105 
1 35 LET Et 1 )=9SE-3 
1 40 LET BC2)=50E-3 
I 45 LET Dt2)=55E-3 
1 50 LET EC2)=45E-3 
1 55 LET B( 3)=10E-3 
160 LET D( 3>=13E-3 
165 LET E( 3) = 7E-3 
1 70 LET BC 4) = 5E-3 
175 LET DC 4)=7E-3 
180 LET EC 4) = 3E-3 
185 LET BC5>=1E>3 
190 LET D< 5) = 3E-3 
195 LET EC 5)=0 



'LL1M 



,( I ) . 



.105. 



BEGIN TEST PROCEDURE S 



FOR 'INDEX'S! THRU 5, THEN 
1 10 LET A( 1 ) = I 
115 GO TO 125 
120 LET A( 1) = AC 1 )+l 
125 IF AC 1 )>5 GO TO 410 

ADJUST. AC SIGNAL, 'INPUT', 

TO 200 KHZ BY 1 KHZ RATE 10 

TO REACH, CVOLTAGE 

•ULIM '( 'INDEX') V I 



VOLTAGE .10 V, FREQ RANGE 50 Kl 

KHZ / SEC, CNX HI J-t-1 LO J3S 

AC SIGNAL, NOM ' VOUT ' ( ' I NDEX ') V UL 

'LLIM 'C 'INDEX ■> V, VOLTAGE RANGE V 



♦ I T( 1 > > 

00,0)FA1L: INV0KEC64) 
0)FAIL: INVOKE* 64) 
0)FAIL: INV0KEC64) 



LET WC3> =50E-6 
GO TO 22 5 
*(TU>), WC3) )FAIL: INVOKEC64) 



3>FA1L: INVOKEC 



. 12 V, CNX HI J4-8 LO J3S 

130 ACVSV ( 1, !0,0. 1 )FAIL:INV0KE(64) 

135 SSWSR C I ,577)FAIL:INV0KEC64) 

1 40 LET TC 1 )=50 

145 k'(3) =.1 

150 IF WC3) <50E-6 LET W( 3) =50E-6 

1 55 ACVSV C 1 , 1000«C TC 1 ) >, UC3) )FAIL : INVOKEC 64) 

160 WAITC 100) 

16 5 WC 1 ) = 1 

170 wie> =i0i 

I 75 DVMSU C2, 

180 SSWSR ( 1, 

185 DVMSU (2,1 

190 U<4) = 1 

195 LET Tf 2>=1E36 

200 WC3) =•! 

205 IF WC 3) <50E- 

210 IF NOT WC 1 ) 

21 5 ACVSV ( 1, 1000 

220 WAITC 100) 

225 Wt2> =1000*( TC 1 

230 WAITC C 1/10)*1000 

235 WAITC 100) 

240 DVMMU (2, VC 1 ), 10 

245 LET M( I )=V(2> 

250 LET TC3>=ABSt BCAC 1 ))-MC t ) 

255 IF TC3)>=T(2) GO TO 275 

260 LET TC2)=T( 3) 

265 LET T(4) = T< 1 ) 

270 LET TC 5)=M( 1 ) 

275 LET T( 1)=TC 1 )♦! 

280 IF T(l)<=200 GO TO 200 

285 LET TC 1 ) = TC 4) 

290 W< 3) =. I 

295 IF WC3) <50E-6 LET W 

300 IF NOT WC 1 ) GO TO 315 

305 ACVSV ( 1 , 1000*( T( 1 ) ), W(3) 

310 WAITC 100) 

315 WC2) =1000*(TC 1 ) ) 

320 LET M( 1 )»T< 5) 

32 5 CMPAH(0,MC l)-ECA(l)),DCACl)),l 

330 DVMSUC2- 1000,0) FAIL: INVOKEC 64) 

335 WC4) = 

340 SSWSR C0,570)FAIL: INV0KEC64) 
MEASURE, CFREO INTO 'FREQ ' C 'I NDEX * ) ) , AC SIGNAL, VOLTAGE 
.10 V, FREQ RANGE 50 KHZ TO 200 KHZ, CNX HI J4-1 LO J3S 

345 CTRSI C3. 0, 3. 0.2)FAIL: INVOKEC 64) 

350 SSWSR C 1,582)FAIL: INV0KEC64) 

355 CTRSI C0.0,3,0,2)FAIL: INV0KEC64) 

360 CTRSF C 3,3- I) FAIL) INV0KEC64) 

365 W(22) si 

370 WAITC 100) 

375 CTRMF ( 4.MC 1 ) ,M( 2) ) FAI L! INVOKEC 64) 

380 LET M( 1 )=MC 11/1000 

385 LET CCA( 1 ) )=Mt 1 ) 

390 CTRSI C 3,0,3, 0,2)FAILi INV0KEC64) 

395 WC22) = 

400 SSWSR (0. 5B2)FAIL: INVOKEC 64) 
END, FOR S 

405 GO TO 120 



= 50E- 



)FA1L: INVOKEC 64 



,H!,L0) 



RECORD. 'FREQ', CI THRU 5) TO EXTERNAL 

410 DRITEC 7,0,C( 1 ),5,G( 6) ) 

415 IF G(6)>0 INV0KEC64) 
FINISH S 

420 INVOKEC66) 

425 RESETC7. 1 ) 

430 CLOSEC 7.GC6) ) 

435 IF GC6>*0 INV0KEC64) 

440 STOP 
TERMINATE, ATLAS PROGRAM S 

445 INV0KEC66) 

450 RESETC 7- 1 ) 

455 CLOSEC 7.GC6) ) 

460 IF G(6>>0 INV0KEC64) 

465 STOP 



1 m ti 



9'S 



(ATLAS Test Procedure) 



TERMINATE $ 



Fig. 7. Listing of an ATLAS test procedure interleaved with 
the equivalent ATS BASIC code. This listing is generated by 
compiler phase V. 
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This compilation will execute quickly because the 
$THRU command will terminate compilation at the 
first logical point after the first error is detected. This 
is generally at the end of a compiler phase, or after 
the preferred listing is generated and the preferred 
source saved, on disc file S20000 in this case. From 
the preferred listing, the user can resolve keypunch 
errors, syntax errors (formal statement structural 
errors) and undefined statement numbers, and can 
prepare a correction tape or deck referencing the 
statement numbers on the preferred listing. 

For the second compilation the following options 
might be used: 



These commands will be saved 
with corrected ATLAS at S20001 . 



$SAVE ATLAS S20001 
SATE D315 
$A/I D313 
$XREF LBL, SIG 
$THRU CONFIG 
SUPDATE WITH RDR 
SINSERT S20000 
$END 



This compilation will process source file S20000, as 
modified by the update tape, through the first four 
compiler phases. Errors involving relationships be- 
tween statements, incorrect resource specifications, 
or errors in the A/I definition will be detected by this 
compilation. 

After resolving any errors of this type, the next 
compilation can be expected to produce code that is 
ready to test. The commands would be: 



This command is saved. 



$SAVE ATLAS S20000 

$OBJECT B1000 

$LIST BASIC 

SDEBUG 

SUPDATE WITH RDR 

SINSERT S20001 

SEND 



Errors in an ATLAS test procedure that are dis- 
covered during execution of the ATS BASIC test pro- 
gram can be easily fixed using BASIC and the cor- 
rections noted for a single final ATLAS recompilation. 

Top-Down Design 

The optimal implementation of ATLAS on HP 
9500 Series Systems required three large processors 
(ATE, A/I, and the ATLAS Compiler). This complex 
design task was efficiently accomplished by a top-down 
design which resulted in certain advantages to the user 
as well as the designer. While the purposes of the 
three processors are different, their source languages 
and organizations are similar in many respects. 
There are two advantages to this. First, the user inter- 



face to each processor, in terms of source language, 
command structure, operating procedures, and ter- 
minology, is consistent throughout the system. Sec- 
ond, the highly structured top-down implementa- 
tion makes use of common modules to accomplish a 
large portion of the processing. 

The two most important areas of commonality in 
the design are the executive control structure and the 
I/O interface (input/output to operating system and 
computer peripherals). The executive control pro- 
gram is the main program in each processor. It con- 
trols the execution of subprocessors, creates, opens, 
positions, and closes files for the subprocessors, and 
maintains a global data area for communications 
with the subprocessors. The executive control pro- 
gram for each processor is the same except for tabular 
data. 

Because the ATLAS compiling system is highly 
dependent on the I/O and file structure of the oper- 
ating system, the compiling system interfaces not di- 
rectly with the operating system, but through a stan- 
dardized interface that can be adapted to different 
operating systems. A considerable effort has been 
made to allow the transfer of the ATLAS system to a 
different environment with minimum effort, because 
it is anticipated that HP ATLAS will eventually be 
made available with operating systems other than 
the disc based operating system presently used by 
9500 Series Automatic Test Systems. 

Two major results of having common executive 
and I/O structures are worthy of note. First, new com- 
piler sections or existing ones were easy to rearrange 
by simply changing tables in the executive. Second, 
compiler speed was improved during development 
by better than a factor of two by making changes only 
in the I/O section, which is where the compiler 
spends most of its time. 

The next level of commonality occurs in the pro- 
cessing and listing sections of the processors. Com- 
mon software modules use different data (keyword 
dictionaries and other tabular data) depending on 
whether the processing is for the ATLAS Compiler 
or the ATE or A/I Processors. Because of the com- 
monality between the three processors and certain 
file structures, the same programs are able to generate 
a variety of listings. For example, the formatted list- 
ings from the ATE and A/I Processors, the preferred 
ARINC ATLAS listing, and the interleaved ATLAS/ 
ATS BASIC listing are all generated by a common pro- 
gram. A common procedure is used throughout the 
compilation system to handle all error conditions. 
This processing handles user diagnostics (warnings, 
syntax errors, semantic diagnostics) as well as system 
errors (I/O errors, user file reference errors). 

A very important compiler technique consists of 
analyzing source text using syntax graphs, which are 
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HP ATLAS Language Words 
and Compiler Commands 



Procedure Oriented Verbs 



DEFINITION VERBS 

BEGIN Used to start test program or BLOCK 

TERMINATE Used with BEGIN. Last statement of test procedure. 
DEFINE Used to define sources, sensors, loads, messages, and 

procedures. 
END Delimiter for a PROCEDURE, BLOCK, IF/THEN/ELSE se- 

quence, or FOR/WHILE loops. 
DECLARE Used to declare variable types. 

FOR UUT Enables UUT name and model number to be variables. 

COMPILER DIRECTIVES 
DISCARD 
REPEAT 
LEAVE ATLAS/ 

RESUME 

ATLAS 
PERFORM 
PERFORM 

EXTERNAL 



PREPARE/ Forms a pair to set up a condition and trigger a sequence 

EXECUTE of operations which must occur within a specified period 

WITHIN of time. 

SYNC WHEN Defines the synchronizing of signals and/or conditions. 



Used to throw out storage no longer needed 
Used to repeat a series of tests or test steps. 
Used to insert non- ATLAS comments 
program. 



in an ATLAS 



References a defined ATLAS procedure. 
An extension to ARINC ATLAS to enable the user 
to perform non-ATLAS functions in an ATLAS pro- 
gram. Can reference ATS-BASIC, FORTRAN, or assembly 

routines. 



EXECUTABLE VERBS 

CALCULATE Specifies computation. 

Relates a labeled value to a specified limit or limits. Sets GO, 

NOGO flags. 

Used to delay execution of test program for a specified interval. 

To present a temporary message or value to operator on CRT or 

numerical display. 

Denotes program sequence that is executed when IF statement 

condition is false. 

Load data in predefined LIST locations. 

To terminate testing and return test equipment to quiescent 

state. 

Names a looping structure with a control variable. 

Used to go to test and/or step out of normal sequence. 

Contains conditional expression to be evaluated as true or false. 

Used to print test results or messages to the operator. 

To identify and store program variable data in historical records. 

To identify present value of measurement with another label and 

save it for later in test procedure. 

Execute specified statement when specified condition is fulfilled 

or insert manual direction into test sequence. 

Contains conditional expression for looping structure. 

Signal Oriented Verbs 

SINGLE ACTION VERBS 

CLOSE To gate a source, sensor, or load function to the unit under test. 

CONNECT To connect pin connectors of unit under test to source, sensor, 

or load. 

Used to open switch at output of power or signal source or at 

input to measuring instrument. 

Used to set up power or signal sources or measuring instru- 
ments. 

Used to open a specific connection through a switching matrix. 

To read present value of sensor function and retain that value, 

labeled 'measurement', until a new reading is taken. 
MULTIPLE ACTION VERBS 
APPLY For source and load functions in sequence: set up, connect, 

and close. 

Used to set up, close, and read signal from unit under test or 

stimulus source. 

To open, disconnect, and set up source, load, or sensor to 

quiescent state. 

Continuously READS and DISPLAYS measurement value. 

Combines MEASURE and COMPARE statements. Compares 

measurement to predetermined value, sets GO, NOGO flags. 
COMPLEX ACTION VERBS 



COMPARE 

DELAY 
DISPLAY 

ELSE 

FILL 
FINISH 

FOR 

GOTO 

IF 

PRINT 

RECORD 

SAVE 

WAIT FOR 

WHILE 



OPEN 



SETUP 



DISCONNECT 
READ 



MEASURE 



REMOVE 



MONITOR 
VERIFY 



ADJUST 



DO 



START WHEN/ 
STOP WHEN 
WAIT FOR 



Forms a pair with TO MAXIMIZE, TO MINIMIZE or TO 
REACH. Creates source-sensor loop that uses sensor feed- 
back to control a stimulus application. 

Used with DIGITAL TEST noun to perform combination of 
digital stimulus, response, mask, save, and compare opera- 
tions in an iterative manner. 

Used to define time interval based on some signal, slope 
or other value. 

Causes a suspension of testing until some unit under test 
sensor criteria is satisfied. 







Nouns 




AC SIGNAL 




LOGIC LOAD 


SHORT 


AM SIGNAL 




LOGIC REFERENCE 


SQUARE WAVE 


COMMON 




MANOMETRIC 


STEP SIGNAL 


DC SIGNAL 




PAM 


SUP CAR SIGNAL 


DIGITAL TEST 


PULSED AC 


SYNCRO 


EARTH (GROUND) 


PULSED DC 


TIME INTERVAL 


EVENTS 




RAMP SIGNAL 


TRIANGULAR 


FM SIGNAL 




RANDOM NOISE 


WAVE 


IMPEDANCE 




RATIO 


SIGNAL 


LOGIC CONTROL 


RESOLVER 




LOGIC DATA 




ROTATION 

Modifiers 




AC-COMP 




IMP 


PWR-SP-DENS 


AC-COMP-FREQ 


IND 


Q 


ALT-RATE 




IN-PHASE 


QUAD 


AMPL-DENS 




MOD-AM PL 


REF-VOLT 


AMPL-MOD 




MOD-AMPL-PP 


RES 


ANGLE 




MOD-DIST 


RINGING 


BANDWIDTH 




MOD-FREQ 


RISE-TIME 


CAP 




MOD-OFFSET 


RMS-VOLTS 


CAR-AMPL 




MOD-PHASE 


ROUNDING 


CAR-FREQ 




NEG-SLOPE 


SAMPLE-WIDTH 


CAR-HARMONICS 


NOISE 


SETTLE-TIME 


CAR-PHASE 




NOISE-P 


SKEW-TIME 


CAR-RESID 




NON-HARMONICS 


SLEW-RATE 


COUNT 




NON-LIN 


SYNC 


CURRENT 




OVERSHOOT 


+ , -SLOPE 


CURRENT-LMT 


P-AMPL 


TIME 


CURRENT-ONE 


PEAK-DEGEN 


TIME-ASYM 


CURRENT-QUIES 


PERIOD 


TIME-JIT 


CURRENT-ZERO 


PHASE-A,AB,AC 


TRIG 


DC- OFFSET 




PHASE-ANGLE 


TYPE 


DELAY 




PHASE-B.BA.BC 


UNDERSHOOT 


DISS-FACTOR 


PHASE-C,CA,CB 


VOLTAGE 


DISTORTION 




PHASE-JIT 


VOLTAGE-AV 


DROOP 




PHASE-SHIFT 


VOLTAGE-ONE 


DUTY-CYCLE 




+ , -PHASE 


VOLTAGE-P 


FALL-TIME 




POS-SLOPE 


VOLTAGE-PP 


FORMAT 




POWER 


VOLTAGE-QUIES 


FREQ 




PRESHOOT 


VOLTAGE-TRMS 


FREQ-DEV 




PRESS-A, G 


VOLTAGE-ZERO 


FREQ-ONE 




PRF 


VOLT-LMT 


FREQ-QUIES 




PULSE-CLASS 


WORD-LENGTH 


FREQ-ZERO 




PULSE-WIDTH 


ZERO-INDEX 


HARMONICS 




PWR-LMT 








Compiler Commands 


Command 




Description 


Applicable 
Processor 

ATLAS A/I ATE 


SINSERT 


Contro 


s source of program input from files or • • • 




system 


I/O devices, including optional state- 




ment number range specification. 




SUPDATE 


Provides batch-edit capability based 


on • • • 


WITH 


ATLAS test-step numbers. 




$OMIT 


Used with UPDATE to delete statements • • • 




from a 


Drogram. 




$END 


Used with INSERT or UPDATE to indicate • • • 




an End of File. 




SBATCH 


Provides entry to BATCH control routine to • 



SATE 



$A.I 



execute ATLAS, A/I, and ATE compilations 
as specified in a BATCH control file. 
In ATLAS and A/I Processor, used to specify 
preprocessed configuration file. In ATE Pro- 
cessor, used to specify where processed 
configuration information is to be stored. 
In ATLAS, used to specify preprocessed 
adapter/interface description. In A/I 
Processor, used to specify where pro- 
cessed adapter/interface description 
is stored. 
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$SAVE Specifies output destination of source or 

preferred ATLAS (A/I or ATE). 

$BASIC Specifies output destination of BASIC 

source code. When multiple files are 
generated, they sequentially increment. 

$OBJECT Specifies output destination of executable 
object code. When multiple files are 
generated, they sequentially increment. 

$GO Same as SOBJECT, but execution of first 

object segment immediately follows 
completion of compilation. 

SSEGMENT Provides override of segment size speci- 
fied in ATE configuration file on either a 
percentage basis or on an immediate 
segment break if no percentage is specified. 

$THRU Controls partial compilation of ATLAS pro- 

grams by terminating after a specified 
phase or number of errors. 

SDEBUG Provides execution of standard debug rou- 

tine at key points during execution of ATLAS 
object code. 

$LIST For control of source, preferred 

ATLAS (A/I or ATE) or mixed ATLAS/ 
BASIC listings. 

SNUMBER Controls test and step number sequencing 
and increment size. 

$XREF Controls listing of label, pin, and signal re- 

quirements analysis cross references. 



PRICE IN U.S.A.: 

951 OD Option 100 or 9500D Option 180: $22,000 first purchase; $12,000 each 
subsequent purchase. These options add ATLAS capability to 951 0D and 
9500D Automatic Test Systems. Price includes ATLAS Compiler, ATE Pro- 
cessor, A/I Processor, run-time software, and configured ATE file. 
MANUFACTURING DIVISION: AUTOMATIC MEASUREMENT DIVISION 
974 East Arques Avenue 
Sunnyvale, California 94086 U.S.A. 
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generated off-line by a special processor. Often a cer- 
tain amount of translation is also performed during 
this syntax checking. In the HP ATLAS Compiler 
this technique is extended and used throughout the 
system. Every process that uses the internal form of 
the ATLAS (or ATE or A/I) program as its primary in- 
put data is controlled by the way the input token 
stream (see "Phase I" above) corresponds with a 
grammar specifically defined for that process. In the 
HP ATLAS Compiler there are seven such "syntax 
driven processes, differing only in their specific gram- 
mars and some low-level subroutines that are in- 
voked as a result of comparing the input token 
stream with a specific grammar. Most of the software 
for these seven processes consists of modules that are 
common to all of them. Once these were designed, 
implementation of each separate process was re- 
duced to dealing only with its unique aspects, a great 
simplification. 

Finally, the same development language and de- 
bugging tools were used by all members of the pro- 
ject team, and each was improved during the project 
to achieve the maximum leverage possible. 
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Automatic 4.5-GHz Counter Provides 
1-Hz Resolution 

This new frequency counter offers high performance for 
telecommunications and other applications at a modest 
cost. Systems compatibility and built-in diagnostics 
enhance its value. 

by Ali Bologlu 



AUTOMATIC MICROWAVE frequency measure- 
ments to 18 GHz and beyond are the special ca- 
pability of Hewlett-Packard's Model 5340A Fre- 
quency Counter. 1 The general-purpose HP Model 
5345A 2 measures frequency automatically to 4 GHz 
when equipped with the 5354A Automatic Fre- 
quency Converter plug-in. It also measures time inter- 
val, period, ratio, and other parameters. 

Now a new counter, Model 5341A, strikes a mid- 
dle ground for the user who needs to measure fre- 
quency to 4 GHz or so, but doesn't need the universal 
capabilities of a general-purpose plug-in counter. 
Model 5341A (Fig. 1) is a 4.5-GHz automatic fre- 
quency counter that provides a high level of perfor- 
mance at a modest cost. An optional version that has 
a 1.5-GHz upper frequency limit offers even greater 
economy. 

The counting principle used in the new counter is 
an automatic heterodyne frequency converter techni- 
que similar to that used in the 5345A plug-in. 3 The 
user has a choice of automatic mode, in which the 



counter searches its entire range and measures the 
lowest-frequency signal, or manual mode, in which 
the search is restricted to one of ten narrower bands 
as selected by the user. 

Model 5341A is compatible with the HP interface 
bus (HP-IB). 4 As many as fifteen devices can operate 
on the bus, so the new counter can be part of an easily 
implemented automatic measurement system. 
Equipped with the appropriate options, Model 
5341A can communicate digitally with printers, cal- 
culators, card readers, computers, and other devices. 
All of its front-panel controls except power on/off 
can be remotely programmed. 

Front-Panel Inputs and Controls 

The new counter has two inputs, a 50fl, 50-MHz-to- 
4.5-GHz input and a 1-Mft, 10-Hz-to-80-MHz input. 
Specified sensitivity of the 4.5-GHz channel is -15dBm 
in automatic mode and -20 dBm in manual mode. 
Fig. 2 shows measured sensitivities for a typical 
counter. Sensitivity of the 80-MHz channel is 10 mV 




Fig. 1. Model 5341 A measures 
frequencies from 10 Hz to 4.5 GHz 
with maximum resolution of 1 Hz. 
Operation can be manual or 
automatic. An optional 1.5-GHz 
version is also available. 
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Specification 



Typical: 

Automatic 

Mode 




' I I I I 1 L_l_ 

.6 1.2 1.8 2.4 3.0 3.6 4.2 
Frequency (GHz) 



Fig. 2. 5341 A sensitivity at 50D. input. 

rms sine wave. 

A range switch on the front panel selects the input 
channel to be used. Also on the range switch is a self- 
check position. Another switch selects the resolu- 
tion of the measurement in decade steps from 1 Hz to 
1 MHz. The counter can display ten digits with appro- 
priate annunciators, enough to provide 1-Hz resolu- 
tion over its full range. A mode switch selects either 



automatic or manual mode, and a band-select push- 
button is provided for switching bands in the manual 
mode. 

Counter Organization 

Fig. 3 is a general block diagram of the new 
counter. 10 MHz from the crystal time base oscillator 
goes to the time base generator and to a multiplier 
chain that produces all the comb lines (local oscilla- 
tor frequencies) needed for heterodyne mixing. 
Lines at 500, 750, and 1000 MHz are produced by 
printed-circuit-board multipliers. Lines at 1.5, 2.0, 
2.5, 3.0, 3.5, and 4.0 GHz are generated in a hybrid 
module. In the optional 1.5-GHz version of the 
counter the hybrid module is deleted. 

The IF module has a switchable upper frequency 
limit; it is nominally 530 MHz except for the two 
lowest-frequency comb lines, for which it is 280 MHz. 
Also in the IF chain are two peak detectors and a fre- 
quency discriminator that control the automatic ac- 
quisition algorithm. The output of the IF module is 
prescaled by 20 and sent to the counter chain. 
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Fig. 3. 50-MHz-to-4.5-GHz frequency range is divided into ten bands by switching different 

local oscillator frequencies to the input mixer. Band switching can be manual or automatic. Two 

peak detectors and a frequency discriminator control the automatic acquisition algorithm; they 

also provide diagnostic information. 
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All digital control of the counter is vested in a state 
machine. Its algorithm is shown in Fig. 4. 

Counter Operation 

In the automatic mode, the counter continuously 
sequences through its ten frequency bands by switch- 
ing appropriate comb lines to the input mixer. This 
proceeds until a signal is detected in the IF channel 
by the fact that both peak detectors and the frequency 
discriminator are triggering. These conditions as- 
sure that the intermediate frequency signal is of the 
proper magnitude to be counted (-1 to +6 dBm) and 
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Fig. 4. Algorithm for 
trols counter operation. 



the state machine that con- 



is within the frequency range of the counting chain, 
which is 500 MHz. The counter then resets to its 
lowest band and reacquires the signal to assure that 
the intermediate frequency is an upper sideband of 
the comb line used. The frequency of the IF signal is 
then counted. The state machine identifies the comb 
line frequency the search has stopped on, adds it to 
the counted IF, and displays the result. 

Overlap between bands is a minimum of 30 MHz, 
which determines the counter's tolerance to fre- 
quency modulation on input signals near the band 
edges. FM peak-to-peak deviation tolerance rises to 
±250 MHz, the bandwidth of the IF channel, for sig- 
nals near the band center. 

In the hybrid structure that generates the upper 
comb lines, each line is activated by a PIN diode 
switch (see Fig. 5). This allows fast switching be- 
tween bands, making it possible for the counter to ac- 
quire a signal in 600 microseconds, worst case, in the 
automatic mode. In the manual mode, where the 
search is over a narrower range, worst case acquisi- 
tion time is only 100 /xs. 

Automatic and Manual Modes 

In the automatic mode the counter will measure 
and display the lowest-frequency CW signal that ex- 
ceeds its minimum sensitivity. If the signal level is in- 
sufficient for the automatic mode but sufficient for 
the manual mode an asterisk appears in the display. 

In the manual mode the correct frequency is found 
by first pushing the reset button and then sequential- 
ly pressing the band select pushbutton. Should no 
signal be present in a band, the comb line frequency 
associated with that band is displayed. When a sig- 
nal is encountered it is measured and displayed. The 
first frequency displayed is the correct one. Pressing 
the band select button once more would yield the 
lower sideband of the next comb line, the image re- 
sponse, which would be the wrong answer. 

Manual mode enables the user to search within 
any of the ten frequency bands. This is advantageous 
when attempting to find and measure several signals 
in a complicated spectrum, or for systems applica- 
tions where low acquisition times are needed. 

Built-in Diagnostics 

When the range switch is moved to the check posi- 
tion a 500-MHz signal is applied to the mixer assem- 
bly, IF module, prescalers, and counter chain. Thus 
the counters are exercised at their highest operating 
frequency instead of the customary 10 MHz. With the 
instrument in automatic mode the 500 MHz is also ad- 
ded to the contents of the counter chain to check for 
proper operation of the acquisition algorithm. 

An internal switch causes the states of the two 
peak detectors and the frequency discriminator to be 
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Microwave Counter," Hewlett-Packard Journal, April 
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Fig. 5. Hybrid module generates the upper local oscillator frequencies and provides for rapid 

switching from one to another. Worst-case acquisition time for an automatic search of the full 

frequency range is less than 600 microseconds. 

displayed, as shown in Fig. 6. This information and References 
a flow chart under the top cover of the instrument al- 
low the user to diagnose failures to the subassembly 
level. Fig. 7 shows the flow chart. 

If the instrument operates properly in the self- 
check mode but not in use, an external source and the 
displayed qualifiers can be used to check the comb 
lines and the input mixer. This is done in manual 
mode. If the three qualifiers are active in the image 
band instead of the proper band the problem is the ab- 
sence of the associated comb line. If no count occurs 
in two adjacent bands and self-check has been satis- 
factorily completed, the input mixer is probably 
faulty. 
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Fig. 6. An internal switch causes the counter to display the 
states of the two peak detectors and the frequency dis- 
criminator in the IF channel (three digits at left). These are 
used with the flow chart of Fig. 7 for troubleshooting. 
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DIAGNOSTIC CHART 

Internal Test Switch (A19S1) aids troubleshooting to the subassembly level (RF Multiplier, Digital, 
Swttchable Filter, Mixer). When A19SI is in the test position AUTO/MAN in manual and resolution 
'< 10 kHz, three qualifiers appear on the 5341A display. A one ("1") indicates the presence of a quel- 
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Fig. 7. Diagnostic flow chart is under top cover of counter, 
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SPECIFICATIONS 

HP Model 5341 A Frequency Counter 



Input 1 

RANGE: 50 MHz to 4.5 GHz 

IMPEDANCE: 50S1 nominal 

CONNECTOR: Precision Type N 

SENSITIVITY: -15 dBm (AUTO operating mode); -20 dBm (MANUAL 

operating mode) 
MAXIMUM INPUT: +20 dBm 
DAMAGE LEVEL: +30 dBm 
OPERATING MODES: 

AUTO: Counter automatically selects and displays lowest frequency within 
its sensitivity range; 

MANUAL: Measurement band is selected manually, and counter measures 
within a 525 MHz range above displayed band number (in the 500 MHz 
and 750 MHz bands, counter measures within a 250 MHz range). 
MEASUREMENT TIME: Acquisition time + gate time 
ACQUISITION TIME: 600 /iseo (AUTO operating mode); 100 ^sec (MANUAL 

operating mode) 
FM CHARACTERISTICS: Tolerates ±250 MHz maximum deviation (0-500 

MHz and 1.0-4.5 GHz) and ±125 MHz maximum deviation (500 MHz-1.0 

GHz) in center of bands; bands overlap 30 MHz at band edges. 

Input 2 

RANGE: 10 Hz to 80 MHz 
IMPEDANCE: 1 Mfl shunted by 50 pF 
CONNECTOR: Type BNC female 
COUPLING: ac 
SENSITIVITY: 10 millivolts 
MAXIMUM INPUT: 5 volts peak-to-peak 

DAMAGE LEVEL: 400 volts dc; 250 volts rms ac, 10 Hz to 100 kHz, decreasing 
6 dB per octave to 80 MHz 

Time Base 

CRYSTAL FREQUENCY: 10 MHz 
STABILITY: 

AGING RATE: <1 x 10~ 7 per month 

TEMPERATURE: <±1 x 10~ 6 over the range 0°C to 50°C 

LINE VARIATION: <±1 x 10~ 7 , ±10% from nominal 
OUTPUT FREQUENCY: 10 MHz, S2.4V square wave (TTL compatible) available 

from rear panel BNC. 
EXTERNAL TIME BASE: Requires 10 MHz approximately 1.5V p-p sine wave or 

square wave into 1 kn via rear pane) BNC. 



Optional Time Base (Option 001) 

Option 001 provides an oven-controlled crystal oscillator time base with an aging 

rate near that of a time standard. This option results in better accuracy and longer 

periods between calibration. A separate power supply keeps the crystal oven 

on and up to temperature when the instrument is turned off as long as it remains 

connected to the power line. 

FREQUENCY: 10 MHz 

AGING RATE: < ±5 x 1 0~ 1 °/day after 24- hour warm-up, for less than 24-hour off 

time, and <1.50 x 10 _7 /year. 
SHORT TERM STABILITY: 1 x 10~ 11 for 1 s avg. time; 1 x 10" 11 for 10 s 



avg. time; 2x10 1 1 for 100 s avg. time 
LINE VARIATION: <1 x 10~ 10 for ±10% change from nominal. A 10% voltage 



change will cause a frequency change of <1 
n-9 



10 



' for <2 minutes. 



10 y frequency change over the range 0° to 50 D C. 



TEMPERATURE: <7 : 

WARM-UP: Within 5 x 10~ 9 of final value 20 minutes after turn-on, at 25°C. 

FREQUENCY ADJUSTMENT RANGE: >±1 x 10~ 6 (>±10Hz from 10MHz) with 

18-turn control. 
FREQUENCY ADJUSTMENT RESOLUTION: 1 x 10~ 9 (0.01 Hz) 

General 

ACCURACY: ±1 count ±time base error 

RESOLUTION: Front panel switch selects 1 MHz, 100 kHz, 1 kHz, 1 kHz, 1 00 Hz, 

10 Hz, or 1 Hz. 
DISPLAY: Ten-digit sectionalized LED display and appropriate measurement 

units of kHz, MHz, or GHz. 
SELF CHECK: Counts and displays 1 GHz for resolution chosen. 
SAMPLE RATE: Continuously adjustable from 40 msec to 10 seconds and HOLD. 
OPERATING TEMPERATURE: 0°C to 50°C 

REMOTE PROGRAMMING AND DIGITAL OUTPUT: Optional (Option 011) 
via 24-pin, series 57 Microribbon connector. Program and output information 
are 7-bit ASCII code. 
PRICES IN U.S.A.: 
5341A Frequency Counter, $3,600 
Option 001 High-Stability Time Base, $500 
Option 002 Rear Panel Input Connectors, $105 
Option 003 1.5 GHz Frequency Range, less $1,000 
Option 01 1 Remote Programming-Digital Output, $390 
MANUFACTURING DIVISION: SANTA CLARA DIVISION 

5301 Stevens Creek Boulevard 
Santa Clara, California 95050 
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A New Instrument Enclosure with Greater 
Convenience, Better Accessibility, and 
Higher Attenuation of RF Interference 

Evolutionary changes in the way electronic circuits are 
packaged have called for a new approach to enclosure 
design. Described here is the result of a corporate-wide 
effort to meet customers' changing requirements. 

by Allen E. Inhelder 



ANEW DIRECTION IN ENCLOSURE design was 
taken some fourteen years ago with the develop- 
ment of a universal instrument enclosure system at 
Hewlett-Packard. This system (Fig. 1) directly ad- 
dressed the problem of how to group instruments, 
whether on the bench or in a rack, a problem that had 
been growing more acute as the number of instru- 
ments used in measurement setups continued to 
grow. 

This enclosure system made it practical to stack in- 
struments neatly for bench use while at the same time 
providing a convenient means 
for mounting the instruments 
directly in a rack. It was also es- 
thetically more appealing than 
the simple boxes that had been 
the norm, and it provided more 
convenient access to internal 
parts and more efficient use of 
space than the earlier chassis- 
deck-slipped-into-a-box ap- 
proach. During subsequent 
years, the basic concept was 
adopted by a number of other 
manufacturers, attesting to the 
wide acceptance of this approach to enclosure design. 

Changing Requirements 

As time went on, however, continuing changes in 
the nature of electronic instrumentation created new 
needs in enclosure systems. Foremost among these 
was the need for even better accessibility to internal 
parts as circuits were packed in more densely. Not 
only was access needed from the top and bottom, as 
provided by the 1961 enclosure system, but from the 
sides, front and back as well. 




Front-panel space was growing scarce. As more ca- 
pability was concentrated in smaller spaces, the area 
for mounting a growing number of controls, displays 
and nomenclature shrank, so it became more and 
more difficult to arrange controls for convenient 
operation. 

Radiated electrical interference was also becoming 
a significant problem. As the transition times of digital 
signals were shortened to the nanosecond region, 
instruments were radiating a greater amount of high- 
frequency energy, creating potential problems for 
users operating sensitive in- 
struments in close proximity. 
Cracks between a top cover and 
a front panel or along the edges 
of plug-ins provided leakage 
paths for RF energy, requiring 
expensive metal gasketing to 
keep the radiation confined to 
the inside of the instrument. 

At the same time there was a 
growing need for a small uni- 
versal enclosure design. As the 
circuits within instruments 
were miniaturized to an in- 
creasing degree, more and more instruments were 
housed in enclosures that did not fill the standard 
19-inch rack width. There were very few of these 
smaller instruments when the 1961 cabinet was de- 
veloped, so small instrument enclosures at that time 
were designed for grouping in combining cases or in 
rack adapter frames. These combining cases and rack 
adapter frames, however, began to assume costly pro- 
portions as more of them were required to house the 
increasing variety and number of small instruments, 
and they did not make maximum use of space. 
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Fig. 1. System I cabinets introduced in 1961 were designed 
to allow the same instrument to be used either on the bench 
or mounted in a rack. Plastic feet fit over a cabinet below, 
enabling instruments to be stacked conveniently for bench 
use. Removal of the feet and installation of simple angle- 
iron brackets in the space provided enabled installation of the 
same instruments directly in a standard relay rack. 



A Fresh Start 

Clearly, there was a need for a new approach to 
the kind of enclosure that instruments could be put 
into. Because of numerous other problems that de- 
signers in HP's various divisions had been experi- 
encing in anticipating customer needs — such as 
the limited number of standard sizes that sometimes 
caused an instrument to be larger than it really 
needed to be — it was decided to bring together indus- 
trial designers from the major HP divisions to work as 
a team designing a new enclosure system. In this way 
it was anticipated that various customer require- 
ments related to the packaging of a product would be 
accommodated in the new design. 

The basic design approach was to be "inside-out", 
in which all the servicing, manufacturing, electrical 
mechanical, and thermal needs would be met first, 
after which the esthetics of the design would be 
considered. 

From this effort, a new cabinet system, known 
within the company as System II, was developed. It 
has greater strength but is lighter than the earlier 
design, it provides better accessibility for servicing 
and more versatility in configuration and it inher- 
ently provides significant attenuation of unwanted 
RF energy. 

Multipurpose Framework 

The framework of the new enclosure is shown 
in Fig. 2. This frame is rigid by itself and does not de- 
pend on decking, front and rear panels, or covers for 



strength as the older design did. It gives the designer 
greater freedom in the product design. 

The heart of the design is the front-panel frame, an 
aluminum die casting that has integral pads for 
mounting the side members, mounting holes for fas- 
tening the front panel, recesses for links that lock ad- 
jacent enclosures together, slots for plug-in latches, 
and narrow channels for holding top, side, and bot- 
tom covers. In addition, mounting holes are provid- 
ed for dividers that may be used for plug-in compart- 
ments or other front-panel subdivisions, either verti- 
cally or horizontally. 

A key part of the design is the narrow channel for 
mounting covers (Fig. 3). These U-shaped slots serve 
as wave traps that reduce the radiation of (or sus- 
ceptibility to) unwanted RF energy. As a further pre- 
caution, small ridges aligned in the direction of cover 
insertion provide high-pressure points for estab- 
lishing good electrical contact every inch or so. Only 
RF energy at wavelengths much shorter than those of 
concern can escape between these contact points. 
Channels on the side covers provide the same kind of 
RF seal along the sides, as does a similar arrangement 
under the lip of the covers at the rear. The covers, 
however, are each retained by a single captive screw, 
enabling quick removal for servicing. 

The sizes of other holes in the external envelope, 
such as those needed for mounting the feet, were re- 
duced to practical minimums. The overall RF atten- 
uation achieved by these measures is indicated in 
the graphs of Fig. 4. 

The plastic feet are compatible with the earlier 




Fig. 2. Frame of the new enclosure system. Countersunk 
holes are for mounting internal parts that have captive nuts. 
Threaded holes are for attachment of external parts, such as 
handles, rack-mount brackets, and other fasteners. Slots 
along the bottom inner edge of the front frame are receptacles 
for latches that retain plug-ins. 
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Fig. 3. Rear view of the front-panel frame shows the RFI- 
trap channels Into which the top, side and bottom covers are 
inserted. Ridges provide high-pressure contact points for 
limiting the wavelength of RF energy that may leak out. 



cabinet design so there is no problem when products 
in the new enclosure are stacked with those in the 
earlier style cabinet. Positive instrument location is 
provided for the plastic feet and the tilt-up bails. Both 
front and rear feet accept the tilt-up bails so an in- 
strument can be tilted up at the rear to give it a more 
convenient "tilt-down" stance when it is placed 
above eye level. 

Maximized Panel Area 

Unlike the earlier design, the front-panel frame 
uses all the available area in full multiples of vertical 
EIA/IEC increments (multiples of 1 3 A inches). The ear- 
lier design allowed vertical space for accommodating 
rack shelving, so a filler strip was added to fill in the 
resulting gaps when instruments were rack 
mounted. In the new design, the front-panel frame 
overhangs the lower side members, completely fill- 
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Fig. 4. Attenuation ofRF energy achieved by the new enclosure design. The values represented 
are conservative, actual measurements made with a bare enclosure being 10-15 dB greater. The 
performance actually achieved by any given instrument, however, depends on such matters as 
the shape and size of holes cut into the panels, on whether metal or plastic control shafts are 
used, and on the signals present on open connectors. 
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Fig. 5. /Vew cabinet design 
maximizes the available front- 
panel area for uncrowded control 
lay-out. 



ing the allotted rack space while still allowing room 
for the rack shelves. 

The front panel mounts to the framework with 
screws that are accessible from the outside. The panel 
may therefore be designed for removal, thus pro- 
viding access to panel-mounted components with- 
out requiring the disassembly of any other part of 
the instrument. The system thus has the potential 
for reducing service time significantly. 

Because the front panel does not serve as a struc- 
tural member, it does not need rounded edges for 
strength, thus increasing the amount of usable 
panel space (Fig. 5). This reduces the crowding of 
controls so instruments can be easier to operate. 

The rear panel also mounts in a die-cast frame, sim- 
plifying its removal. Front- and rear-panel frames are 



joined by die-cast side struts, leaving plenty of open 
space for accessibility to internal components (Fig. 6). 
The four struts are identical, and the same type is 
used for all cabinets regardless of height or width. 
Thus it is economical to manufacture the struts in five 
lengths, giving a wide assortment of available cabinet 
sizes. Also, since all the main structural members 
are die cast, the dimensional tolerances are tighter 
than is possible with sheet metal, making parts re- 
placement easier. 

All screws used in the cabinet assembly are of the 
self-locking type with an inserted plastic patch on the 
threads, per MIL-F-18240C, that prevents the screw 
from working loose when subject to vibration. As a 
result, the assembly is much more rigid than would 
have been possible using lock washers. 




Fig. 6. New enclosure makes 
maximum use of interior space. 
Circuits are accessible for trou- 
ble-shooting from the top, bottom 
and sides. 
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Easier Carrying 

Front-panel handles, now an optional item, cant 
outwards. This has two benefits. Access to controls 
along the edge of the front panel is improved, and 
when the instrument is carried by the handle, the 
angle is the proper one for the hand (Fig. 7). The 
handle was also reshaped to provide a more com- 
fortable fit to the hand. The optional rack-mounting 
brackets may be installed with or without the handles 
in place. 

A bail handle is available for the smaller instru- 
ments (see Fig. 6). The side handle, which is fitted 
to the top cover of submodules, is a long strap. This 
provides more freedom in finding a balance point. 
The cover panels used with the strap handles have a 
shallow depression for the strap. This performs an 
alternate function by providing a place for mounting 
rack slides. 

Modular Submodules 

The smaller enclosures in the new system are di- 
mensioned to be exact submultiples of the standard 
rack width design. Rack mounting adapters are there- 
fore not required for the smaller instruments — a sim- 
ple extender to reach full rack width is all that is 
needed (Fig. 8). 

Instruments can be fastened together horizontally 
and vertically with simple links (Fig. 9). Because the 
submodules are dimensioned as part of the total sys- 
tem, standard full width and full height cover panels 
and handles can be used where smaller instruments 






Fig. 8. Smaller Instruments either singly or In groups, fit 
standard El A rack dimensions with the addition of simple 
extensions. 

are to be combined more or less permanently in a 
grouped arrangement. 

Where instruments are to be grouped temporarily, 
links that allow quick assembly and separation (Fig. 
10) can be installed by using threaded holes already 
provided in the framework. 

Environmentally Evaluated 

The thermal characteristics of the new cabinet de- 
sign have been thoroughly evaluated and guide- 
lines supplied to HP instrument designers to aid in 
maintaining heat rise within conservative limits, 
thus obtaining improved reliability and assuring 




Fig. 7. Canted handle provides a more comfortable grip for 
carrying an instrument. 



Fig. 9. Instrument frames are linked together with universal 
brackets that can be used for either horizontal or vertical 
instrument groupings. Linked frames can be fitted with full- 
size covers and handles to make a single, unified package. 
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Fig. 10. Temporary groupings of instruments are enabled by 
quick-disconnect links that are fitted to the lower instrument 
and insert into slots in the front-panel frame of the upper in- 
strument. The rear is retained by straps that bolt to builtin 
pads. The links also work with horizontal groupings. 



longer product life. The cabinet design is in compliance 
with various environmental and safety specifications 
such as the Underwriters Laboratory proposed speci- 
fication 1244, MIL-S-901 shock test, and MIL-STD 
167 Type I vibration test, among others. 

All in all we believe that we have arrived at a supe- 
rior design that offers many benefits to the users of in- 
struments packaged in this enclosure. 
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